【レポート】「AWS勉強会 若手エンジニア大集合 in 札幌」に参加してきました #cm_sansan
こんにちは。池田です。こちらの記事でご案内していたイベント「AWS勉強会 若手エンジニア大集合 in 札幌」の参加レポートです。
はじめに
会場をご提供くださった株式会社インフィニットループさんありがとうございました。
レポート
イベントはSansan株式会社 菅井 祐太朗さんによる「ビアバッシュ形式ですが、くれぐれも飲み過ぎないように」というありがたい注意と共に乾杯で始まりました。
ビールやサワーのほか、ソフトドリンクとおやつもありました。オリジナルロゴ入りのラムネにびっくり!
RSpec for AWSフルマネージドサービス
Sansan株式会社 藤井 洋太郎さんのセッション。
自己紹介では、担当されている名刺アプリ「Eight」に関する業務のほか「ももクロの話だけで新卒内定を勝ち取った」というお話で会場を驚かせていました。
- Eightというサービス
- ユーザ数は150万人
- 年間1億枚の名刺データを処理(国内で行われる名刺交換のおよそ10%)
- Eightを支えている技術
- RailsアプリケーションとAWS(AWSサービスのうち約半数を利用している)
- AWSフルマネージドサービスを活用
- フルマネージドサービスを利用する上での悩みもある
- ローカル開発環境、テスト環境がない、またはテストを省略、簡略化してしまう
- 品質や生産性の低下に繋がるリスクが顕在化
- フルマネージドサービスを活用しながらも、ローカル開発環境とリスクの問題をどうするか
- 主要機能は意地でもローカル開発環境で動かそう
- ローカル開発環境で動かす際の高速化を追求
- Dockerを活用してより効率的に
- 結果、現在のローカル開発環境では利用しているAWSサービスと「同等の仕組み」が全て立ち上がる
- 「同等の仕組み」とは
- いわゆる「Fake系」を駆使してローカル開発環境で完結させる
- ちょっと大変だったけれど、ローカルに開発環境とテスト環境の構築ができて幸せになれた
- とはならなかった...
- テストを実行するとおよそ4倍も時間がかかるようになったものが出てきた
- RSpecのタグ機能やテーブルのメモ化などを駆使して許容範囲に収めた
- 開発環境には問題もなく、テスト実行も速くなって幸せになれた
- とはならなかった...
- ローカル環境で十を超えるサービスを立ち上げるのが苦痛
- インストールのタイミングやメンバー個人の環境によってバージョンが異なる問題
- Dockerの導入
- Docker Hub公式Imageを利用
- 公式Imageがないものは自作してAmazon ECR(Amazon Elastic Container Registry)で管理
- まとめ
- 妥協なきローカル環境開発構築が不可欠
オンプレを触ってた人間がクラウドを触って約1年間で考えさせられたこと
クラスメソッド若手エンジニアのトップバッター吉江 健斗のセッション。
実はセミナーイベントでの登壇は今回が初ということで、少し長めの自己紹介でアイスブレイク。
- コストを考えるのは誰?
- オンプレなら機材調達など、クラウドなら毎月の利用費など、コストを考え気にするのはお客様
- オンプレ環境のコスト
- システム設計次にインフラコストを試算
- 運用開始後のコスト変動は比較的少ない
- クラウド環境のコスト
- 従量課金制の面から導入リソースとそのコストを試算
- 運用開始後のパフォーマンスやトラフィックによってコストの変動が発生する
- オンプレ環境とクラウド環境ではコストに対する考え方が異なってくる
- 設計時のコスト試算が難しく、クラウドの利用に消極的になってしまうことも
- 環境の特性を考慮したコストを把握できる人は誰?
- 色々考えたけれど、答えは出なかった
- でも、エンジニアがコスト面を意識して知識を備えておけば、お客様とのやり取りの中で役に立つ場面がある
- オンプレとクラウドはそんなに違うのか?
- オンプレエンジニア経験が長かったので、クラウドの勉強は触りながら学んだ
- クラウドだからこそ実現しやすいInfrastructure as Code、DevOpsなど個人で試せることで視野を広げられた
- 技術に関する基礎を理解し、応用ができればインフラ環境がオンプレからクラウドになっても、歯が立たないことはない
- 自分の視野を広げ、出来ることを増やす。クラウドサービスをスキル向上のツールにする
- クラウドでもオンプレで使っていた技術が活躍する場面はある(RAIDや監視など)
- まとめ
- コスト感を持って作業ができるエンジニアは重宝される
- オンプレの技術はクラウドに全く通じないわけではない
- クラウド技術は自分の可能性を広げるツール
Eightがサーバーサイド/インフラのメンテナンス性向上のために実現してきたこと
Sansan株式会社 菅井 祐太朗さんのセッション。
自己紹介が終わり、本題に入ったスライド3ページ目でまずこのセッションの核心「必要なタイミングで捨てたり作り直したりできること」と仰っていたのが印象的でした。
- チーム体制
- 1チーム4-5名で7チーム、合計35名程度で構成
- バックエンド開発チーム、モバイルチーム、基盤チーム
- 基盤チームはRailsエンジニアとインフラエンジニアで構成
- 監視システム
- NagiosからMackerelへ変更
- Mackerelの機能はほぼ使っているが、独自でやっていることもある
- AWS Integrationで取得できないメトリクスの取得と監視、粒度の細かいリソースに関するメトリクスの自動取得などLambdaを駆使
- AWS Integrationで取得できないメトリクスの取得と監視
- Auroraのinnodb status
- DynamoDBのキャパシティ消費率計算と監視
- SESのbounse率計算と監視
- 粒度の細かいリソースに関するメトリクスの自動取得
- DynamoDB Stream
- Kinesis StreamのShard
- モニタリング追加が漏れそうなものはCloudWatch APIで取得してMackerelに投稿
- リリースに関する問題点
- デプロイを複数に分けて実行する必要があった
- リリース方法が一本化されていない部分があった
- 手作業が多かった
- リリースにかかる時間が長かった
- 対策として行ったこと
- リリース所要時間の計測
- リリース方法の一本化
- リリースブランチPR自動作成botの導入
- デプロイとassets:precompileの分離
- Golden Image(AMI)作成の自動化
- Blue/Green Deploymentの導入
- 設定ファイルの簡略化 etc...
- リリースブランチPR自動作成bot
- Lambdaが自動的に行う
- Slackに投稿させるので、その日のリリースPRが一覧化
- デプロイとassets:precompileの分離
- デプロイ時にS3へアップロード、CloudFrontで配信させるように
- Golden Image(AMI)作成の自動化
- GitHubでmasterブランチをマージ、Slackにリリースコマンドを投稿
- Blue/Green Deploymentの導入
- アプリケーションログ収集に関する整備を実施して準備を整え導入
- 上記対策を行った結果
- 手作業をほぼ撲滅
- リリース作業がかなり楽になった
- アプリケーションログの課題
- ログレベルがまちまち
- 大量の不要なログ
- 確認はサーバへログインして実施
- ログ問題の対策として行ったこと
- 容量、行数の計測
- 削減目標を決める
- 不要そうなログをまとめた
- ログレベルの整理
- fluentdで収集、Elasticsearch→Kibanaで可視化、分析可能に
- サーバレス化したこと
- Eightにおけるリアルタイムリコメンデーション
- フィードのOGP画像リサイズとキャッシュ機構
- 監視システムの一部
- サーバレスによる課題もある
- 全体像の把握
- エラーハンドリング
- ログ管理のベストプラクティス
- マイクロサービス化した際の認証、ユーザ基盤とのやりとり
- まとめ
- 秘訣はたぶん、必要なタイミングで素早く捨てたり作り直したりできること
- 当たり前のことを当たり前に泥臭く改善
- サーバサイドとインフラで協力して推進
「日次RSSフィード」の開発日誌
クラスメソッド若手代表、サーモン大好き横山 文人のセッション。
発表資料はすでに本人がブログで紹介していますのでそちらをご覧ください。
聴講した感想として、DEMOの際に利用していたJupyterのノートブックが大変興味深かったです。
さいごに
イベントの企画、運営から登壇まで活躍いただいたSansan株式会社の皆さま、ご来場くださった皆さまありがとうございました。
togetterにてまとめを作成していますので「登壇してきたブログ」や「参加してきたブログ」などあればぜひ、ハッシュタグ #cm_sansanをつけてツイートしてください。
最後は登壇されたSansan株式会社のお二人と記念撮影。